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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The Itf-N partitions two groups of interacting entities called IRPManager(s) and IRPAgent(s). 

The interactions between an IRPManager and IRP Agent are specified by the set of IRP specifications the IRP Agent 
supports, and which the IRPManager uses. 

Each YyyIRP (where "Yyy" stands for Alarm, BasicCM, etc.) permits a manager to, via getlRPVersion, inspect it's 
supported IRPVersion(s). Each such IRPVersion uniquely identifies one supported Interface IRP SS. 

Each YyyIRP may also permit an IRPManager to, via getNRMIRPVersions, inspect it's supported NRM 
IRPVersion(s). Each such IRPVersion uniquely identifies one supported NRM IRP SS. 

The 3GPP IRP specifications are expected to evolve. For example, 3GPP Release 6 specifications include more or 
modified features compared to the corresponding set in Release 5. 

An IRPManager and IRP Agent, with implementations conformant to the same IRP specification (at the same 
IRPVersion(s)) will be able to communicate. 

However, an upgrade of the IRPVersion, if not performed by both IRP Agent and IRPManager, can result in inter- 
working failure if Backward Compatibility (BC) issues are not addressed. 

The present document is applicable/relevant to a system context of a group of interacting IRPManagers and IRP Agents 
where some members are using one IRPVersion while others are using an upgraded IRPVersion. 
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Scope 



The present document gives recommendations to develop future IRP specifications in a Backward Compatible (BC) 
way so that the group of IRPManager(s) and IRPAgent(s) are not forced to be upgraded in lock step. 

The business case for supporting such group, as described above, is complex. It may not relate to the functions of the 
supported IRPs alone. Rather, it can relate to the cost of coordination of IRPVersion upgrades, the cost of maintaining 
an old IRPVersion and the cost of using single-vendor or multi-vendor IRP Agents. These considerations are operator 
deployment scenarios specific. 

Clause 4 specifies the Recommendations and clause 5 describes the system context where the Recommendations are 
applicable. 

Editor's Note: The Torward compatability' part is FFS. 
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The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
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• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.101: "Telecommunication management; Principles and high level requirements". 

[2] 3GPP TS 32.102: "Telecommunication management; Architecture". 

[3] 3GPP TS 32. Ill -2: "Telecommunication management; Fault Management; Part 2: Alarm 

Integration Reference Point (IRP): Information Service (IS)". 

[4] 3GPP TS 32.3 11: "Telecommunication management; Generic Integration Reference Point (IRP) 

management; Requirements". 



Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Element Manager (EM): See 3GPP TS 32.101 [1]. 

IRPAgent: See 3GPP TS 32.102 [2]. 

IRPManager: See 3GPP TS 32.102 [2]. 

IRPVersion: See "IRP document version number string" or "IRPVersion" in 3GPP TS 32.311 [4] clause 3.1. 

Network Manager (NM): See 3GPP TS 32.101 [1]. 
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3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ASN. 1 Abstract Syntax Notation One 

BC Backward Compatible or Backward Compatibility 

CMIP Common Management Information Protocol 

CORBA Common Object Request Broker Architecture 

EM Element Manager 

IS Information Service 

IRP Integration Reference Point 

NE Network Element 

NM Network Manager 

NRM Network Resource Model 

VSE Vendor Specific Extension (to 3GPP IRP specification) 

SS Solution Set 

XML extensible Markup Language 



BC between 3GPP TS 32-series specifications 



4.1 Prerequisite 



The words old and new, when qualifying an IRPVersion, refer to a single Interface IRPVersion of the same kind, 
e.g. Alarm IRP. They also refer to NRM IRPVersion of the same kind, e.g. Core NRM. The 'new' refers to a later 
release compared to the 'old'. 

The words old and new, when qualifying an IRPManager, refer to an entity that is using the old or the new (Interface or 
NRM) IRPVersion. 

The words old and new, when qualifying an IRP Agent, refer to an entity that contains an IRP that is supporting the old 
or the new (Interface or NRM) IRPVersion. 

In majority cases, an IRP Agent instance contains multiple IRPs, each of which is using a particular Interface 
IRPVersion. In these cases, each Recommendation statement should be repeated to cover all IRPs involved. 

The Recommendations do not imply that equipment vendors shall always supply their new IRP Agents in compliance to 
the solutions satisfying the Recommendations. The Recommendations simply identify the expected behaviours of a new 
system when it, claiming BC, interacts with an old system. Whether or not an IRP Agent should satisfy the 
Recommendations is a decision of the equipment vendor/supplier. 

The Recommendations do not imply that the next release of 3GPP Interface IRP or NRM IRP specification must be BC 
(to the older one). Whether or not a new release of an Interface IRP or NRM IRP should be BC to its older version is a 
decision of the 3GPP specification author, on a case-by-case basis. 



£75/ 



3GPP TS 32.1 54 version 1 0.0.0 Release 1 7 ETSI TS 1 32 1 54 V1 0.0.0 (201 1 -05) 



4.2 Rules 

[REC-1] An old IRPManager inter-operates with an old IRPAgent-A and a new IRPAgent-B. 

The interaction shall be successful in that the IRPManager can obtain the network management 

services (capabilities and features) defined by the old IRPVersion from both IRP Agents. 

The IRPManager needs not have knowledge of new network management services defined by the new 

IRPVersion. 

[REC-2] A new IRPManager inter-operates with a new IRPAgent-A and an old IRPAgent-B. 

The interaction shall be successful in that the IRPManager can obtain the network management 
services defined by (a) the new IRPVersion from IRPAgent-A and (b) the old IRPVersion from 
IRPAgent-B. 

NOTE: If the next minor and/or major release of 3GPP Interface IRP or NRM IRP specification is BC (to the older 
one), one could reduce or eliminate the difficult coordination task to introduce IRPVersion upgrades in a 
large management domain containing multiple IRPManagers and IRP Agents. 

It can be more cost-effective if IRPVersion upgrades to individual entity (i.e. IRPManager and IRP Agent) are 
done at different times. 



£75/ 



3GPP TS 32.154 version 10.0.0 Release 10 



ETSI TS 132 154 VI 0.0.0 (2011-05) 



BC context 



5.1 



General 



This clause defines the context under which the requirements specified in the present document are appHcable. 

The word 'old' qualifies the related entity (i.e. the AlarmlRP of an IRPAgent instance or Alarm IRPManager) that is 
using an older 3GPP IRPVersion (called old version). The word 'new' qualifies the related entity that is using a newer 
(upgraded) 3GPP IRPVersion. 

EXAMPLE: A hypothetical 3GPP TS 32. 123 V6.0.0 is considered the old version with reference to 

3GPP TS 32.123 V6.1.0. The two versions in question can belong to the same or different major 
releases (e.g. Rel-5 or Rel-6). 

The box labelled EM in figure 5.1 conveys the same idea as the box of the same label in the System Context- A of other 
IRP specifications such as Alarm IRP IS 3GPP TS 32. Ill -2 [3]. 

One or all EM-labelled boxes of figure 5.1 can be interchanged with the NE-labelled box (see System Context-B of 
other IRP specifications such as Alarm IRP IS 3GPP TS 32.1 1 1-2 [3]). The NE entities are not shown in order to make 
the figure easier to read. 

Itf-N 
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Figure 5.1 : Overall BC System Context 

In general, an IRPAgent instance may contain several Interface YyyIRP instances and associated supporting Yyy NRM 
IRPs (where one IRP can be for example Alarm IRP, Test Management IRP, or "Notification IRP", etc and where the 
other IRP can be for example Generic IRP). The Interface and NRM YyyIRP specifications of particular IRPVersion(s) 
together specify the behaviour of an Interface IRP and the supporting NRM IRP (s). 

NOTE: The IRPVersion concept is related to the IRP. 

The IRPVersion concept is not related to the IRPAgent as this may contain multiple IRPs. 

Given this background, the BC issues are addressed at two separate but related levels as described in clauses 5.2 
and 5.3. 
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5.2 



IRP level 



The two diagrams here illustrate conceptually the two possible contexts when we address BC at this IRP level. 
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Figure 5.2: Specification BC System Context 

An YyyIRP instance supports a particular Interface IRP Version and a particular set of NRM IRP Versions. 
An IRPManager uses a particular Interface IRPVersion and a particular set of NRM IRPVersions. 

If an YyyIRP instance supports Interface IRPVersion-X and NRM IRPVersions-Y, then it can interact successfully with 
an IRPManager that uses the same IRPVersions. This is illustrated by the case of the "Old IRPManager" and the "Old 
IRPAgent" of the bottom diagram (and note that the diagram does not show the NRM IRP version support). 

If this same YyyIRP instance upgrades its Interface IRPVersion-X to X2 that is BC to X, then it can interact 
successfully with an IRPManager that uses the Interface IRPVersion-X or IRPVersion-X2. The top diagram of 
figure 5.2 illustrates this case (and note that the diagram does not show the NRM IRP version support). 

If this same YyyIRP instance upgrades its NRM IRPVersion-Y to Y2 that is BC to Y, then it can interact successfully 
with an IRPManager that uses the NRM IRPVersion-Y or NRM IRPVersion- Y2. The top diagram of figure 5.2 
illustrated this case (and note that the diagram does not show the NRM IRP version support). 

Given the above, the BC issues addressed at the present document level are: 

• How to determine if an IRP IS or SS specification (Interface IRP or NRM IRP) is BC to an earlier version ? 
This can be addressed in another way. 
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What are the BC-rules that the author of a 3GPP IRP specification should use to extend an old-version to 
produce a new version that can claim BC (to that old-version) ? 

At this level, the specification author shall define BC-rules for each of the following: 

• Interface IRP- Requirements. 

• Interface IRP IS. 

• Interface IRP SS(s). 

• NRM IRP requirements. 

• NRM IRP IS. 

• NRM IRP SS(s). 

• Data Definition IRP IS. 

• Data Definition IRP SS(s). 

One reason why the specification author addresses BC at this IRP level is that, for certain technologies, such as 
CORBA, it is possible that one entity using (compiles with) one IRP SS specification (i.e. the CORBA SS) while the 
other communicating entity using a new but BC version can interact successfully (such as the case of the IRPManager 
and IRPAgent-A of [REC-1]). 

5.3 IRPAgent level 

Figure 5.3 illustrates the two possible contexts when addressing BC at this IRPAgent level. 
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Figure 5.3: System/Implementation BC System Context 
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NOTE 1 : An IRP Agent instance contains multiple YyyIRP instances such as AlarmlRP, NotificationIRP, 

TestManagementIRP, etc. Each YyyIRP instance implements/supports the corresponding YyyIRP 
specification of a particular IRPVersion. 

Suppose IRPAgent-A contains YyyIRP of Interface IRPVersion-4, YyyIRP of Interface IRPVersion-5 and YyyIRP of 
Interface IRPVersion-6 and all IRPs support NRM IRPVersion-7 (see Note 2), this IRPAgent-A is BC if it can inter- 
operate successfully with the following: 

• IRPManager 1 using Interface IRPVersion-4 or 3 using NRM IRPVersion-7 or 6. 

• IRPManager 2 using Interface IRPVersion-5 or 4 using NRM IRPVersion-7 or 6. 

• IRPManager 3 using Interface IRPVersion-6 or 5 using NRM IRPVersion-7 or 6. 

NOTE 2: All IRPs contained by the same IRP Agent instance should support the same set of NRM IRPVersions. 
It is anticipated that the IRP Agent level BC solution includes: 

• An IRP Agent service allowing IRPManager to discover all the IRP Agent supported Interface IRPVersion(s). 

• An IRP Agent service allowing IRPManager to discover the IRP Agent supported NRM IRPVersion(s). 

• An IRP Agent service allowing IRPManager to discover the reference/address of the IRP instance (of the 
IRP Agent) supporting a particular Interface IRPVersion. 

The two diagrams in figure 5.3 illustrate the two possible ways to support BC at this so-called IRP Agent level. 

The IRPVersion-new needs not to be BC to IRPVersion-old. In the case that IRPVersion-new is BC to IRPVersion-old, 
it is EM supplier's choice if "IRP level" or "IRP Agent level" solution will be used to support BC. In the case that the 
IRPVersion-new is not BC to IRPVersion-old, then the EM supplier will have no choice but to use "IRP Agent level" 
solution if it wants its EM to support BC. 

NOTE 3: IRP Agent service supporting "discovery" (as stated by the above three bullets) is not illustrated in the two 
diagrams 
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6 BC Recommendations 

6.1 Requirement 

The Requirement specification is in subclause 4.2 Rules. 

6.2 IS-level 

There is no text specifically written related to IS-level specification for BC systems. The two system context diagrams 
of subclauses 5.2 and 5.3 would be necessary and sufficient to describe the management services provided by EM to 
support the so-called Old IRPManager and New IRPManager. 

6.3 SS-level 

6.3.1 CORBA 

For CORBA Solution Set, the IRP Agent level (see subclause 5.3) context would be used. 

6.3.2 Void 

6.3.3 File format description XML 

Editor's Note: This part is FES. 

6.3.4 File format description ASN.1 

Editor's Note: This part is FES. 

6.3.5 SOAP 

Editor's Note: This part is FES. 
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Annex A (informative): 

BC and Conformance Tests 



This annex illustrates that: 

• an IRP, implementing a new-version IRP specification that is BC to an old-version IRP specification, may or 
may not be compliant to the old-version IRP specification. 
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Figure A.1 : BC and Conformance Tests Scenario 

Suppose 3GPP has an older-version IRP specification (the "Old-version IRP specification" box) and there is a 
valid/correct implementation (the "Old-IRP" box). 

Suppose also that 3GPP produce a "New-version IRP specification" by extending the "Old-version IRP specification" 
using the BC-rules. 

The "New-IRP" should interwork with IRPManager that uses the "New-version IRP specification". 
This "New-IRP" should also interwork with IRPManager that uses the "Old- version IRP specification". 

The "Old-IRP" should pass the conformance test that is based on (see "depend" relation) the "Old-version IRP 

specification". 

Likewise, the "New-IRP" should pass the conformance test that is based on the "New-version IRP specification". 

However, this "New-IRP" may not be able to pass the conformance test that is based on "Old-version IRP specification" 

(see "test (should fail)" relation). 

Likewise, the "Old-IRP" should not be able to pass the conformance test that is based on "New-Version IRP 

specification". 
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Annex B (informative): 
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